-
Notifications
You must be signed in to change notification settings - Fork 465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: fix undocumented assumptions about the timing of tsfn calls #995
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Node.js didn't need the test change because we increased the array size to be over 1000 elements:
nodejs/node@7abc7e4#diff-7025abd678052220b281a720c8e5f2b995120dd65ccd8f8557b0158a1a43025bR10
I think this change is good as it is, but just wanted to suggest some alternatives.
@@ -25,11 +25,9 @@ async function test(binding) { | |||
binding.threadsafe_function[threadStarter](function testCallback(value) { | |||
array.push(value); | |||
if (array.length === quitAfter) { | |||
setImmediate(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or you could use process.nextTick
if you'd like to keep it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know the exact intention of deferring the close of TSFN here. However, tests all passed with or without deferring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, original TSFN implementation was re-scheduling each call on the next physical UV loop tick (which was terribly slow), so the setImmediate()
got a chance to run right after the first invocation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KevinEady @gabrielschulhof any input on using/not using process.nextTick(). I'll plan to land this tomorrow unless I hear from you so that we can get back to green CI.
So the related patch doesn't seem to be released on the latest v16.x. We don't have GitHub Actions setup for nightly Node.js builds... (as nightly build probably fails for arbitrary reasons)�¯_(ツ)_/¯, what can we do here? This test fixup doesn't break all existing releasing lines. And I've tested against the latest main branch of Node.js. |
Ran on a few of the versions in our CI, its possibly there are other places with the same issue:
|
@legendecas , Well actually just looks like the similar typed version of the test likely needs the same fix |
CI runs were good. I'll land to unbreak the CI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
PR-URL: #995 Reviewed-By: Michael Dawson <[email protected]>
Landed as: da3bd57 CI across versions on what's landed: |
CI run was all green. @legendecas thanks for helping get this resolved so quickly. @indutny-signal thanks for helping out as well. |
PR-URL: nodejs#995 Reviewed-By: Michael Dawson <[email protected]>
PR-URL: nodejs#995 Reviewed-By: Michael Dawson <[email protected]>
PR-URL: nodejs/node-addon-api#995 Reviewed-By: Michael Dawson <[email protected]>
PR-URL: nodejs/node-addon-api#995 Reviewed-By: Michael Dawson <[email protected]>
PR-URL: nodejs/node-addon-api#995 Reviewed-By: Michael Dawson <[email protected]>
PR-URL: nodejs/node-addon-api#995 Reviewed-By: Michael Dawson <[email protected]>
Fixes #994